Info-Mac 4/Info_Mac IV CD-ROM (Pacific HiTech Inc.)(August 1994).iso/Periodicals/CSMP/C.S.M.P. Digest, Issue 3.024

Internet Message Format | 1994-06-09 | 71KB

From: [e-mail] (Francois Pottier)
Subject: csmp-digest-v3-024
Date: Sat, 7 May 94 13:07:29 MET DST

C.S.M.P. Digest             Sat, 07 May 94       Volume 3 : Issue 24

Today's Topics:

        Anyone have routine for random numbers?
        Async CD-ROM Drivers?
        Comparing 2 LongDateTime's
        Copying graphics the fast way (in assembler)
        Favorite C++ Book?
        Native PPC Interrupt Control?
        SetDialogDefaultItem in a modal dialog
        Symantec has an FTP site!
        pascal and c libraries



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                        Sends you a summary of commands
    subscribe csmp-digest Your Name    Adds you to the mailing list
    signoff csmp-digest            Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail]. Currently no previous volumes of the CSMP
digest are available there.

Also, the digests are available to WAIS users as comp.sys.mac.programmer.src.


-------------------------------------------------------

>From [e-mail] (Thai Binh Truong)
Subject: Anyone have routine for random numbers?
Date: 21 Apr 94 20:47:04 GMT
Organization: San Jose State University - Math/CS Dept.

I'm looking for a routine that will generate
normally distributed random numbers.  If anyone
know of any other routines that comes close to
it, please post. Thanks in advance.

-Thai


+++++++++++++++++++++++++++

>From Jim Conner <[e-mail]>
Date: 22 Apr 1994 16:00:20 GMT
Organization: Cornell University

Subject: Anyone have routine for random numbers?
From: Thai Binh Truong, [e-mail]
Date: 21 Apr 94 20:47:04 GMT
In article <[e-mail]> Thai Binh Truong,
[e-mail] writes:
>I'm looking for a routine that will generate
>normally distributed random numbers.  If anyone
>know of any other routines that comes close to
>it, please post. Thanks in advance.
>
>-Thai
>

Try looking in Numerical Recipes in Pascal (or C or Fortran, take your
pick).  Each book in this set has several routines for generating uniform
deviates as well as other types of distributions.  The routine for
normally distributed random numbers looks like this (in Pascal):

{ Global stuff... }
GasdevIset: integer;
GasdevGset: real;
begin
    GasdevIset := 0;

{ Returns a normally distributed deviate with zero mean and unit
variance,     }
{ using UniDev as the source of uniform deviates.
       }

 function gasdev: extended;
  var
   fac, r, v1, v2: extended;

 begin
  if GasdevIset = 0 then
   begin
    repeat
     v1 := 2.0 * UniDev - 1.0;
     v2 := 2.0 * UniDev - 1.0;
     r := sqr(v1) + sqr(v2);
    until (r < 1.0) and (r > 0.0);
    fac := sqrt(-2.0 * ln(r) / r);
    GasdevGset := v1 * fac;
    gasdev := v2 * fac;
    GasdevIset := 1
   end
  else
   begin
    GasdevIset := 0;
    gasdev := GasdevGset;
   end
 end;

See Numerical Recipes for more details.

Jim Conner

+++++++++++++++++++++++++++

>From [e-mail] (Gordon Apple)
Date: 22 Apr 1994 11:55:56 -0800
Organization: (none)

I'm looking for a routine that will generate
normally distributed random numbers.  If anyone
know of any other routines that comes close to
it, please post. Thanks in advance.


      I don't have the exact algorithms handy, but here are a couple of
suggestions (assuming you already have a good uniformly distributed random
number generator):

     If you are just doing things like usual statistics, then the simplest
way is to generate a series of uniformly distributed variables and average
them.  Even small series like 16 or so will give you very good results.

     If you're working far out on the tail (5 or 10 standard deviations),
such as is often the case when working statistical communications problems,
you need something better.  One of the best methods we found for our
simulations was to take a pair of uniformly distributed random variables and
use them to generate a pair of Gaussion rvs.  To do this, you need to use an
exponential to map one variable into a Rayleigh amplitude distribution.  Use
the other to generate a random angle from 0 to 2 * Pi.  Use sin and cos to
get the two (independent) Gaussians.  Works great.  I've used it for years.

G. Gordon Apple, PhD
Advanced ommunications Engineering, Inc.
Redondo Beach, CA

+++++++++++++++++++++++++++

>From [e-mail] (AFC JLloyd)
Date: 22 Apr 1994 19:52:06 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]>, [e-mail] (Gordon
Apple) writes:

>>>
     If you're working far out on the tail (5 or 10 standard deviations),
such as is often the case when working statistical communications problems,
you need something better.  One of the best methods we found for our
simulations was to take a pair of uniformly distributed random variables and
use them to generate a pair of Gaussion rvs.  To do this, you need to use an
exponential to map one variable into a Rayleigh amplitude distribution.  Use
the other to generate a random angle from 0 to 2 * Pi.  Use sin and cos to
get the two (independent) Gaussians.  Works great.  I've used it for years.
<<<

Code to implement this technique can be found in "Numerical Recipes in C".
The code given manages to avoid calling sin() and cos(), but it does require
a log() and a sqrt() (and a float divide).  Here's the basic code:

do {
   v1 = 2.0*ran() - 1.0;
   v2 = 2.0*ran() - 1.0;
   r = v1*v1 + v2*v2;
} while (r >= 1.0);
fac = sqrt(-2.0*log(r)/r);

ran() is a function returning a uniform deviate in the range 0.0 .. 1.0.
After computing the above, you can now get two independent normal deviates
by returning v1*fac and v2*fac.  The deviates have zero mean and unit variance.

Jim Lloyd
[e-mail]


---------------------------

>From [e-mail] (Rich Siegel)
Subject: Async CD-ROM Drivers?
Date: Wed, 13 Apr 1994 21:46:18 GMT
Organization: Bare Bones Software


(This is a philosophical question. If you can't spell "philosophy",
you're excused. :-])

A number of us, having nothing better to do, were idly wondering about
the pros and cons of the new SCSI Manager. One of its benefits is the
ability to disconnect and reconnect (provided the device supports it),
which leads directly to the ability for a driver to support async I/O
operations.

This obviously works well for high-speed SCSI devices and copying.
You can also perform some SCSI operations such as a format
asynchronously at the application level (drivers rarely, if ever, need
to format a disk); the app can issue the format, disconnect, and then
handle UA and reconnect.

However, my colleagues and I can't pin down and specific technical
benefits, besides the pure sex appeal, for supporting async I/O in a
CD-ROM driver.

Are we missing something? Can someone, or several someones, enumerate
the specific benefits for supporting async SCSI operation for CD-ROM
drives?

For the benefit of all, please post to this newsgroup.

R.

--
Rich Siegel % [e-mail]    % Principal, Bare Bones Software
--> For information about BBEdit, finger [e-mail] <--

"...yeah, I inhaled, and then I drank the bong water. So what're
you gonna do about it?" - Dennis Miller, on Bill Clinton

+++++++++++++++++++++++++++

>From [e-mail] (Pete Resnick)
Date: Thu, 14 Apr 1994 00:25:43 -0500
Organization: University of Illinois at Urbana-Champaign

In article <[e-mail]>, [e-mail] (Rich Siegel) wrote:

>(This is a philosophical question. If you can't spell "philosophy",
>you're excused. :-])

I think I can spell it pretty well.

>This obviously works well for high-speed SCSI devices and copying.

Why does anyone care about async I/O on a high-speed device other than
pure sex appeal? On a high-speed device, I/O should happen so quickly that
calling it async should have no effect to your program.

>However, my colleagues and I can't pin down and specific technical
>benefits, besides the pure sex appeal, for supporting async I/O in a
>CD-ROM driver.
>
>Are we missing something? Can someone, or several someones, enumerate
>the specific benefits for supporting async SCSI operation for CD-ROM
>drives?

The best reason for any async I/O on any device is multitasking. It drives
me absolutely bananas that FSRead is written synchronously, because to
read 1 Meg at a time, people call:

        buffPtr = NewPtr(1000000);
        count = 1000000;
        FSRead(refNum, &count, buffPtr);

This is ESPECIALLY horrible on a slow device, and worst over the network
(consider going over a 9600 bps ARA link). Why can't people do it right
and say:

        paramBlock->ioParam.ioCompletion = nil;
        paramBlock->ioParam.ioRefNum = refNum;
        paramBlock->ioParam.ioBuffer = NewPtr(1000000);
        paramBlock->ioParam.ioReqCount = 1000000;
        PBReadAsync(paramBlock);
        while(paramBlock->ioParam.ioResult > noErr)
            HandleEvents();

So, the reason that a CD-ROM drive should have async I/O is exactly
because the damn things are slow. In all honesty, I don't see that there
is any other reason to have async I/O except to allow you to call your
event loop during I/O operations. Everything else is secondary.

Personally, I wish that FSRead called _Read asynchronously and provided a
filterProc which could continue to receive events while the damn read was
going on.

I am driven almost to tears every time I try to get anything done while
doing copies in the Finder (which, contrary to its documentation, can't do
a background copy to save its life) from a slow device because my machine
either comes to a complete screeching halt or behaves so poorly that I
can't get anything done (like typing a news article).

CD-ROM's should have async I/O before any device which is faster.

pr
--
Pete Resnick        (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (joe zobkiw)
Date: Thu, 14 Apr 1994 13:20:42 GMT
Organization: Datawatch Corporation

In article <[e-mail]>,
[e-mail] (Pete Resnick) wrote:

>
> CD-ROM's should have async I/O before any device which is faster.
>

Don't forget floppy disks...believe it or not...some people still use them!
:)

___________________________________________________________
_/_/_/_/   Joe Zobkiw                                   ,,,
    _/     Senior Software Engineer                     - -
  _/       Datawatch Corporation                         L
_/_/_/_/   [e-mail]                          -

+++++++++++++++++++++++++++

>From [e-mail] (Robert Cassidy)
Date: Thu, 14 Apr 1994 10:23:20 -0700
Organization: TLG Project

In article <[e-mail]>, [e-mail] (Rich Siegel)
wrote:

>
> (This is a philosophical question. If you can't spell "philosophy",
> you're excused. :-])
>
> A number of us, having nothing better to do, were idly wondering about
> the pros and cons of the new SCSI Manager. One of its benefits is the
> ability to disconnect and reconnect (provided the device supports it),
> which leads directly to the ability for a driver to support async I/O
> operations.
>
> This obviously works well for high-speed SCSI devices and copying.
> You can also perform some SCSI operations such as a format
> asynchronously at the application level (drivers rarely, if ever, need
> to format a disk); the app can issue the format, disconnect, and then
> handle UA and reconnect.
>
> However, my colleagues and I can't pin down and specific technical
> benefits, besides the pure sex appeal, for supporting async I/O in a
> CD-ROM driver.
>
> Are we missing something? Can someone, or several someones, enumerate
> the specific benefits for supporting async SCSI operation for CD-ROM
> drives?
>
> For the benefit of all, please post to this newsgroup.

Well, here's a prime example. I work in a place where we take ancient Greek
writings (all of 'em) and encode them on CD-ROM. We sent our our first CD
about 8 years ago - we were one of the first. The CD contains about 500MB
of data, and only about 20MB of indices :-(  As the first CD's were going
out a decision was made to create a machine dedicated to searching through
our CD looking for particular instances of words. The machine was based on
an 8MHz 68000 but at 8MHz it was just fast enough to search data at the
same rate that it came in (asynchronously) from the CD-ROM drive
(150K/sec). The whole process takes about 50 minutes.

Most users of our CD are Mac users (~50% worldwide). My Q800 with a 300CD
can search the CD in exactly the same amount of time as the 68000 above
because there is no asynchrounous. I've determined that if I rewrote the
Mac search programs (And I just might) that I would have the following
results:

For a full search (500MB)

                      running time          processing time
PM6100 async         ~30min                                                                <5min
PM6100 sync          ~35min                ~35min

The running time (when the program starts to when the program quits)
doesn't change much - but the processing time (how much I can't give back
to the system) drops drastically. So in 30 minutes (a lot of time in my
opinion) the user can recover 25 of it for other things and probably won't
even know the background task is running.

Just for measure. We have an HP1000 that most of our work is done on. It
takes about 6 hours for a full search with no other users on the system. A
PM8100 working asynchronously from HD could do it in under 5 min.

--
Robert Cassidy
TLG Project
UC Irvine

Let's hope 'Information SuperTollroad' isn't the catchphrase of the next
decade...

+++++++++++++++++++++++++++

>From [e-mail] (Anton Rang)
Date: 15 Apr 1994 00:13:30 GMT
Organization: Minnesota Angsters

In article <[e-mail]> [e-mail] (joe zobkiw) writes:
>In article <[e-mail]>,
>[e-mail] (Pete Resnick) wrote:
>>
>> CD-ROM's should have async I/O before any device which is faster.
>>
>
>Don't forget floppy disks...believe it or not...some people still use them!
>:)

  But they've had asynchronous I/O since the very first Macs!

  (Believe it or not....)
--
Anton Rang ([e-mail])

+++++++++++++++++++++++++++

>From Steve Bryan <[e-mail]>
Date: Sun, 17 Apr 1994 16:47:49 GMT
Organization: Sexton Software

In article <[e-mail]> joe zobkiw,
[e-mail] writes:
>Don't forget floppy disks...believe it or not...some people still use
them!

I was under the impression that the driver for the floppy drive was (and
has been) asynchronous. The fact that it disables interrupts causing
mouse movement to become eratic diminishes the possible benefit of being
asynchronous.
Steve Bryan                  InterNet: [e-mail]
Sexton Software            CompuServe: 76545,527
Minneapolis, MN                   Fax: [phone]

+++++++++++++++++++++++++++

>From Brad Koehn <[e-mail]>
Date: 18 Apr 1994 02:32:37 GMT
Organization: University of Wisconsin

In article <[e-mail]> joe zobkiw,
[e-mail] writes:
>>
>> CD-ROM's should have async I/O before any device which is faster.
>>
>
>Don't forget floppy disks...believe it or not...some people still use
them!
>:)

Floppy I/O is asynchronous, check out a copy of Disk Charmer. It lets you
format floppies in the background. It's pretty chunky on my Duo, but it
works perfectly on a PPC.

_________________________________________________________________________
Brad Koehn          Data Transformations, Inc.        [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Mike Bell)
Date: Wed, 20 Apr 1994 17:34:46 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Rich Siegel)
writes:
> Newsgroups: comp.sys.mac.programmer
> Path: gallant.apple.com!apple.com!taligent!ames!hookup!swrinde!ihnp4.
> ucsd.edu!library.ucla.edu!news.ucdavis.edu!csus.edu!netcom.com!siegel
> From: [e-mail] (Rich Siegel)
> Subject: Async CD-ROM Drivers?
> Message-ID: <[e-mail]>
> Organization: Bare Bones Software
> Date: Wed, 13 Apr 1994 21:46:18 GMT
> Lines: 33
>
>
> (This is a philosophical question. If you can't spell "philosophy", you'
> re excused. :-])
>
> A number of us, having nothing better to do, were idly wondering about
> the pros and cons of the new SCSI Manager. One of its benefits is the
> ability to disconnect and reconnect (provided the device supports it),
> which leads directly to the ability for a driver to support async I/O
> operations.
>
> This obviously works well for high-speed SCSI devices and copying.
> You can also perform some SCSI operations such as a format
> asynchronously at the application level (drivers rarely, if ever, need
> to format a disk); the app can issue the format, disconnect, and then
> handle UA and reconnect.
>
> However, my colleagues and I can't pin down and specific technical
> benefits, besides the pure sex appeal, for supporting async I/O in a
> CD-ROM driver.
>
> Are we missing something? Can someone, or several someones, enumerate
> the specific benefits for supporting async SCSI operation for CD-ROM
> drives?
>
> For the benefit of all, please post to this newsgroup.
>
> R.
>
> --
> Rich Siegel % [e-mail]    % Principal, Bare Bones Software
> --> For information about BBEdit, finger [e-mail] <--
>
> "...yeah, I inhaled, and then I drank the bong water. So what're
> you gonna do about it?" - Dennis Miller, on Bill Clinton
>


 Having async I/O in a CD ROM driver is very useful. It allows you to do
something with the data that you just read while simultaneously reading
another chunk off of the SLOW CD ROM drive. So, if a program is smart enough
to use multiple async reads from disc, effective throughput is greatly
increased by the async driver.


     -Mike






****************************************************************************
Mike Bell                                                     email: [e-mail]
Rock and Roll Project
2 Infinite Loop    MS: 302-3SB
Cupertino, CA  95014



+++++++++++++++++++++++++++

>From [e-mail] (Jens Alfke)
Date: 21 Apr 94 01:03:58 GMT
Organization: Apple Computer

Pete Resnick, [e-mail] writes:
> Why does anyone care about async I/O on a high-speed device other than
> pure sex appeal? On a high-speed device, I/O should happen so quickly that
> calling it async should have no effect to your program.

By those standards I guess a RAM disk might qualify as "high speed" but not
anything else! My hard disk has a 14ms access time, and think of how much the
25MHz 040 in my now-lowly Quadra 700 could get done during those 350,000
clock cycles.

I was under the impression that the CD-ROM driver already did async I/O.
Doesn't QuickTime decode and render one frame while it's reading the next one
from the disk?

> I am driven almost to tears every time I try to get anything done while
> doing copies in the Finder (which, contrary to its documentation, can't do
> a background copy to save its life) from a slow device because my machine
> either comes to a complete screeching halt or behaves so poorly that I
> can't get anything done (like typing a news article).

You need the "ALLRight" utilities from MSA software. It has a background
copying feature (which used to be a standalone utility called COPYright) that
makes copies a breeze. Finder copies are forwarded to a small app that runs
in the background. It does all its I/O asynchronously, with little CPU
hogging even when copying to/from a floppy, a slow file server, or over ARA.
It'll do multiple copies at a time, too.
The other utilities in the package are not too original (a Helium clone, a
very weak SuperBoomerang clone, a BeHierarchic clone, etc.) and have some
serious bugs, but the copy utility is worth the price of the package.

--Jens Alfke
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

+++++++++++++++++++++++++++

>From [e-mail] (Pete Resnick)
Date: Wed, 20 Apr 1994 21:47:49 -0500
Organization: University of Illinois at Urbana-Champaign

In article <[e-mail]>,
[e-mail] (Jens Alfke) wrote:

>Pete Resnick, [e-mail] writes:
>> Why does anyone care about async I/O on a high-speed device other than
>> pure sex appeal? On a high-speed device, I/O should happen so quickly that
>> calling it async should have no effect to your program.
>
>By those standards I guess a RAM disk might qualify as "high speed" but not
>anything else! My hard disk has a 14ms access time, and think of how much the
>25MHz 040 in my now-lowly Quadra 700 could get done during those 350,000
>clock cycles.

I agree completely. I was just playing with what Rich Siegel said. Every
external device should support asynchronous I/O because every external
device is going to be really slow.

>> I am driven almost to tears every time I try to get anything done while
>> doing copies in the Finder (which, contrary to its documentation, can't do
>> a background copy to save its life) from a slow device because my machine
>> either comes to a complete screeching halt or behaves so poorly that I
>> can't get anything done (like typing a news article).
>
>You need the "ALLRight" utilities from MSA software. It has a background
>copying feature (which used to be a standalone utility called COPYright) that
>makes copies a breeze. Finder copies are forwarded to a small app that runs
>in the background. It does all its I/O asynchronously, with little CPU
>hogging even when copying to/from a floppy, a slow file server, or over ARA.
>It'll do multiple copies at a time, too.

But why can't the Finder do this?? Why is it that I need yet another patch
trapping, memory using (no matter how small) extra utility that does
something that could be done infinitely more easily in the Finder, which
should have done it in the first place? The code to write this into the
Finder itself is trivial. This is just a case of sloppy programming that
needs to be fixed, not extra functionality that a third-party program
should be solving.

pr
--
Pete Resnick        (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Robert Cassidy)
Date: Thu, 21 Apr 1994 12:19:25 -0800
Organization: TLG Project

In article <[e-mail]>,
[e-mail] (Pete Resnick) wrote:

[stuff deleted]

> >> I am driven almost to tears every time I try to get anything done while
> >> doing copies in the Finder (which, contrary to its documentation, can't do
> >> a background copy to save its life) from a slow device because my machine
> >> either comes to a complete screeching halt or behaves so poorly that I
> >> can't get anything done (like typing a news article).
> >
> >You need the "ALLRight" utilities from MSA software. It has a background
> >copying feature (which used to be a standalone utility called COPYright) that
> >makes copies a breeze. Finder copies are forwarded to a small app that runs
> >in the background. It does all its I/O asynchronously, with little CPU
> >hogging even when copying to/from a floppy, a slow file server, or over ARA.
> >It'll do multiple copies at a time, too.

Well, not to be an ass or anything but COPYright and Copydoubler don't
always (do they ever) do asynchronous I/O. Those programs work on my Color
Classic and it doesn't support asynch I/O to SCSI. They do their magic just
in stolen cycles  (it's much slower in the background than in the
forground) and actually do their work synchronously (at least on non 040
machines). I know it's picking nits but it is an async discussion...

> But why can't the Finder do this?? Why is it that I need yet another patch
> trapping, memory using (no matter how small) extra utility that does
> something that could be done infinitely more easily in the Finder, which
> should have done it in the first place? The code to write this into the
> Finder itself is trivial. This is just a case of sloppy programming that
> needs to be fixed, not extra functionality that a third-party program
> should be solving.

Apple has been avoiding this situation in its more recent software
(Powertalk at least) in that Powertalk runs as an appe instead of some big
hunk of the system. That way it takes cycles just like any app. I think the
biggest thing the Mac needs at this time is a threaded OS - spin the
copying off on a thread - formatting floppies - launching apps - etc. etc.
Apple has done really well in some things and poorly in others, Powertalk
is *wonderful* in this regard, PrintMonitor is good, but the finder stuff
_rots_. Isn't Apple working on a rewrite of the Finder, though? I thought I
heard rumors of that for 7.8 or something (I don't think it is planned for
7.5)

--
Robert Cassidy
TLG Project
UC Irvine

Let's hope 'Information SuperTollroad' isn't the catchphrase of the next
decade...

+++++++++++++++++++++++++++

>From [e-mail] (Anton Rang)
Date: 21 Apr 1994 05:54:04 GMT
Organization: Minnesota Angsters

In article <[e-mail]> [e-mail] (Mike Bell) writes:
> Having async I/O in a CD ROM driver is very useful. It allows you to do
>something with the data that you just read while simultaneously reading
>another chunk off of the SLOW CD ROM drive. So, if a program is smart enough
>to use multiple async reads from disc, effective throughput is greatly
>increased by the async driver.

  In particular, newer QuickTime versions (from 1.5 or 1.6, I forget
which) take advantage of this to overlap i/o and decompression....
--
Anton Rang ([e-mail])

---------------------------

>From [e-mail] (Steven J. Russell)
Subject: Comparing 2 LongDateTime's
Date: 19 Apr 1994 21:08:02 GMT
Organization: Reed College,  Portland, Oregon


I have a routine that compares two LongDateTime variables and tells me
if the first one is before the second one.  Unfortunately, it converts
the LongDateTime types to LongDateRec types via LongSecs2Date and then
compares the old date format values, branching out at the appropriate
moment.

What I would like to do is skip the conversion to LongDateRec's and then
compare the LongDateTime variables that are passed in.  Inside Mac: Text
says that the LongDateTime is a 64-bit signed representation of the number
of seconds since Jan 1, 1904.  So, I check the high-bit of both and compare
the high-order and low-order longs.  Seems to work most of the time.  However,
I get LongDateTime values that are negative using this scheme (high-order bit
set) sometimes even though the date is, for instance, 18 April 1994!

Does anybody have code to compare LongDateTime's directly without conversion?

BTW, I am doing this for a speed optimization, sincemy program compares dates
and times frequently.

Thanks,
Steven Russell
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Pete Resnick)
Date: Wed, 20 Apr 1994 00:28:41 -0500
Organization: University of Illinois at Urbana-Champaign

In article <2p1h7i$[e-mail]>, [e-mail] (Steven J.
Russell) wrote:

>What I would like to do is skip the conversion to LongDateRec's and then
>compare the LongDateTime variables that are passed in.

This should be pretty easy. In Script.h is a typedef for LongDateCvt,
which gives you the high and low long of each. Here's a routine that
returns 1 if the first is greater, -1 if the first is less than, and 0 if
the first is equal to the second:

short CompareLongDate(LongDateTime *time1, LongDateTime *time2)
{
    LongDateCvt temp1, temp2;
    short returnVal;

    temp1.c = *time1;
    temp2.c = *time2;
    if(temp1.hl.lHigh > temp2.hl.lHigh) {
        returnVal = 1;
    } else if(temp1.hl.lHigh < temp2.hl.lHigh) {
        returnVal =  -1;
    } else {
        if(temp1.hl.lLow > temp2.hl.lLow) {
            returnVal = 1;
        } else if(temp1.hl.lLow < temp2.hl.lLow) {
            returnVal = -1;
        } else {
            returnVal = 0;
        }
        if(temp1.hl.lHigh < 0) {
            returnVal = -returnVal;
        }
    }
    return returnVal;
}

Will that do it?

pr
--
Pete Resnick        (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Peter N Lewis)
Date: Thu, 21 Apr 1994 11:50:56 +0800
Organization: NCRPDA, Curtin University

>What I would like to do is skip the conversion to LongDateRec's and then
>compare the LongDateTime variables that are passed in.  Inside Mac: Text
>says that the LongDateTime is a 64-bit signed representation of the number
>of seconds since Jan 1, 1904.  So, I check the high-bit of both and compare
>the high-order and low-order longs.  Seems to work most of the time.  However,
>I get LongDateTime values that are negative using this scheme (high-order bit
>set) sometimes even though the date is, for instance, 18 April 1994!

Well, LongDateTime is an 64-bit signed number.  But it's very unlikely
that it fills more than 48 bits, right?  So why not take the bottom 24
bits and the next 24 bits (and ignore the top 16 bits), and compare the
top two first, and then the bottom two.  This only requires the date to be
after 19040101, and before 2^48 seconds after that (8 million years I
think :-).

type LongLongInt=record
  hi:longInt;
  lo:longInt;
end;

var
  c1,c2:LongDateTime;
  l1,l2:LongLongInt;
begin
  l1:=LongLongInt(c1);
  l1.hi:=BAND(BSL(l1.hi,8),$00FFFF00)+BAND(BSR(l1.lo,16),$000000FF);
  l1.lo:=BAND(l1.lo,$00FFFFFF);
ditto for l2
  if l1.hi=l2.hi then
    return l1.lo<l2.lo
  else
    return l1.hi<l2.hi
  end-if
end;

Something like that anyway,
   Peter.
_______________________________________________________________________
Peter N Lewis <[e-mail]>       Ph: [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Sean Parent)
Date: Thu, 21 Apr 1994 21:17:50 GMT
Organization: Adobe Systems Incorporated

Since LongDateTime is declared as a comp why not just use ">" - should at
least work in MPW C and Pascal.

Sean
In article <[e-mail]>,
[e-mail] (Peter N Lewis) wrote:
>
> >What I would like to do is skip the conversion to LongDateRec's and then
> >compare the LongDateTime variables that are passed in.  Inside Mac: Text
> >says that the LongDateTime is a 64-bit signed representation of the number
> >of seconds since Jan 1, 1904.  So, I check the high-bit of both and compare
> >the high-order and low-order longs.  Seems to work most of the time.  However,
> >I get LongDateTime values that are negative using this scheme (high-order bit
> >set) sometimes even though the date is, for instance, 18 April 1994!
>
> Well, LongDateTime is an 64-bit signed number.  But it's very unlikely
> that it fills more than 48 bits, right?  So why not take the bottom 24
> bits and the next 24 bits (and ignore the top 16 bits), and compare the
> top two first, and then the bottom two.  This only requires the date to be
> after 19040101, and before 2^48 seconds after that (8 million years I
> think :-).
>
> type LongLongInt=record
>   hi:longInt;
>   lo:longInt;
> end;
>
> var
>   c1,c2:LongDateTime;
>   l1,l2:LongLongInt;
> begin
>   l1:=LongLongInt(c1);
>   l1.hi:=BAND(BSL(l1.hi,8),$00FFFF00)+BAND(BSR(l1.lo,16),$000000FF);
>   l1.lo:=BAND(l1.lo,$00FFFFFF);
> ditto for l2
>   if l1.hi=l2.hi then
>     return l1.lo<l2.lo
>   else
>     return l1.hi<l2.hi
>   end-if
> end;
>
> Something like that anyway,
>    Peter.
> _______________________________________________________________________
> Peter N Lewis <[e-mail]>       Ph: [phone]

--
Sean Parent

+++++++++++++++++++++++++++

>From [e-mail] (Peter N Lewis)
Date: Sat, 23 Apr 1994 12:24:01 +0800
Organization: NCRPDA, Curtin University

In article <[e-mail]>,
[e-mail] (Sean Parent) wrote:

>Since LongDateTime is declared as a comp why not just use ">" - should at
>least work in MPW C and Pascal.

True - but it does it (at least in THINK Pascal) by calling zillions of
_Pack4 (SANE) traps.  By the look of it, it converts the comp to an 80-bit
floating point number and then compares it.  Not exactly efficient.  I
just did a quick test on my LC3, and the SANE code for x<y required
exactly ten times more time than the  code I posted.  Of course, on the
PPC, things might well be different given the PPC executes floating point
faster than integer anyway.
   Peter.
_______________________________________________________________________
Peter N Lewis <[e-mail]>       Ph: [phone]

---------------------------

>From [e-mail] (Alex Metcalf)
Subject: Copying graphics the fast way (in assembler)
Date: Sat, 23 Apr 1994 18:38:29 GMT
Organization: Demon Internet


My (cheap) version of CopyBits, in assembler
- ------------------------------------------

   After I mentioned in a previous note that I had written a custom
copy routine, I got flooded with messages asking if I could post it for
others to see or use. So, here it is!

   This code is taken directly from my new arcade game, to be released
in the next couple of months. I know it may be possible to make the code
faster, but it works fast enough for me. With this and similar routines
in my game, I get an increase of up to 500% over CopyBits and CopyMask.
This is mainly because I do far less checking than CopyBits does.

   Also note that (I assume unlike CopyBits) this code may actually draw
to the screen when the electron beam is half way down the screen. So, the
top half of your graphic may appear slightly after the bottom half. You
need to read up on the Vertical Retrace manager and SlotVInstall if you
want to "sync" your animation with the electron beam of the screen.

   The code copies a rectangle from an offscreen graphics world onto the
screen. The following assumptions are made:

o   You're in 32-bit addressing mode
o   The monitor is in 8-bit (256 colours/grays); 1 byte per pixel
o   The cursor is hidden
o   The source and destination rectangles are the same size
o   The rectangles don't go off the screen or off the GWorld
o   The rectangles are in coordinates which are local to the screen
        (i.e. top left of screen is 0,0)

   There are four globals used:

o   gWorldPixMapBase is the pix map base address of the graphics world.
You use GetGWorldPixMap to get the pix map, and then you use
GetPixBaseAddr to get the base address.

o   gScreenPixMapBase is the pix map base address of the screen.
You get the pix map from the GDHandle of the screen you're using. Then
you use GetPixBaseAddr.

    If you're using the main monitor, you can get the GDHandle for that
monitor by using GetMainDevice ().

o   gWorldRowByteCount is the rowBytes for the graphics world. You get
it like this:

gWorldRowByteCount = (0x7FFF & (**tWorldPixMap).rowBytes);

o   gScreenRowByteCount is the rowBytes for the screen. You get it like
this:

gScreenRowByteCount = (0x7FFF & (**tScreenPixMap).rowBytes);


   I hope the code is useful to someone: you might try using the code,
but it's much better if you read through and understand what's happening,
and then use parts of it in your own game, animation app, or whatever.

   If you don't know how to read assembler, an excellent start is this
book:

How to Write Macintosh Software
by Scott Knaster
Published by Addison Wesley
ISBN 0-201-60805-7

   Have fun!



   Alex Metcalf
   [e-mail]


void RectCopy (Rect tSourceRect, Rect tDestRect)
{
        asm
        {
                movem.l a0-a1/d0-d7, -(sp);

                move.l  gWorldPixMapBase, D0;
                move.w  tSourceRect.top, D1;
                ext.l   D1;
                mulu.l  gWorldRowByteCount, D1;
                add.l   D1, D0;
                move.w  tSourceRect.left, D1;
                ext.l   D1;
                add.l   D1, D0;
                move.l  D0, A0;     // A0 is the source

                move.l  gScreenPixMapBase, D0;
                move.w  tDestRect.top, D1;
                ext.l   D1;
                mulu.l  gScreenRowByteCount, D1;
                add.l   D1, D0;
                move.w  tDestRect.left, D1;
                ext.l   D1;
                add.l   D1, D0;
                move.l  D0, A1;     // A1 is the destination

                move.w  tSourceRect.right, D6;
                move.w  tSourceRect.left, D0;
                sub.w   D0, D6;
                ext.l   D6;         // D6 is the width of rect to copy

                move.l  gWorldRowByteCount, D2;
                sub.l   D6, D2;     // D2 is the source row offset

                move.l  gScreenRowByteCount, D3;
                sub.l   D6, D3;     // D3 is the destination row offset

                move.w  tSourceRect.bottom, D4;
                move.w  tSourceRect.top, D0;
                sub.w   D0, D4;
                ext.l   D4;
                subq.l  #1, D4;     // D6 is number of rows to copy

                moveq.l #4, D5;

                tst.l   D4;
                ble.s   @6;

                move.l D6, D0;
                divs.l D5, D0;
                move.l D5, D7;
                mulu.l D0, D7;
                move.l D6, D1;
                sub.l  D7, D1;
                subq.l #1, D0;
                subq.l #1, D1;
                move.l D0, D6;
                move.l D1, D7;

                @1;
                tst.l D0;
                blt.s @3;

                @2;
                move.l (a0)+, (a1)+;
                dbra d0,@2;

                @3;
                tst.l D1;
                blt.s @5;

                @4;
                move.b (a0)+, (a1)+;
                dbra d1,@4;

                @5;
                adda.l D2, A0;
                adda.l D3, A1;
                move.l D6, D0;
                move.l D7, D1;
                dbra d4,@1;

                @6;
                movem.l (sp)+, a0-a1/d0-d7;
        }
}


--
Alex Metcalf, Mac programmer in C, C++, HyperTalk, assembler

Internet, AOL, BIX: [e-mail]            "Surely you
AppleLink:          [e-mail]@internet#   can't be
CompuServe:         INTERNET:[e-mail]    serious?"
Delphi:             [e-mail]@inet#
FirstClass:         [e-mail],Internet   "I am serious...
Fax (UK):           (0570) 45636                         and don't call
Fax (US / Canada):  011 44 570 45636                     me Shirley."

---------------------------

>From [e-mail] (Bob Jacobsen)
Subject: Favorite C++ Book?
Date: Wed, 13 Apr 1994 21:50:36 GMT
Organization: CERN, the European Organization for Nuclear Research

What books do people recommend for C++ on the Mac?

Two suggestions have been:

1) Learn C++ on the Macintosh, Dave Mark (1993).  Comes with Thin C++ and a
cheap (how much?) upgrade offer.

2) Symantec C++ Programming for the Macintosh, Neil Rhodes and Julie
McKeehan

Neither of these is available at a local bookstore - if you had to order it
from the US and wait a month, which would you pick?

Bob Jacobsen, [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Jaeger)
Date: Thu, 14 Apr 94 11:36:11 CDT
Organization: Kunikpok Kennels and Komputers (Pet Project)

[e-mail] (Bob Jacobsen) writes:

> What books do people recommend for C++ on the Mac?
>
> Two suggestions have been:
>
> 1) Learn C++ on the Macintosh, Dave Mark (1993).  Comes with Thin C++ and a
> cheap (how much?) upgrade offer.
>
> 2) Symantec C++ Programming for the Macintosh, Neil Rhodes and Julie
> McKeehan
>
> Neither of these is available at a local bookstore - if you had to order it
> from the US and wait a month, which would you pick?
>
> Bob Jacobsen, [e-mail]

Hi Bob,
I can't tell you which one to get but I have the Rhodes and
McKeehan book so I can tell you something about it.  The book is in three
parts: The Symantec environment (120pp), Intro to C++ (200pp), Using TCL
(180pp).  There are also several appendices, source listings and a disk
with all the source from the book.  The authors say that the book is a
practical approach not a comprehensive approach.  Believe them.  In my
opinion the first section is a waste of space.  It repeats the
information given in the Symantec manuals.  It is perhaps better than the
material in the actual manuals :-/  but I think the space could have
better been used to increase the size of sections two and three.

The Intro to C++ section isn't that bad.  It gives you a lot of redundant
information about how to use SC++ as does the first section.  It tells
you how to use the class browser for instance (gee that's a toughie).  It
has a long discussion of the global optimizer.  Apparently the authors
wrote the book with a prerelease version of SC++6.0.  They go through
excruciating detail (dissasembled code) to explain how the global
optimizer works and of course they show all the places where it doesn't
(didn't?) work.  IMHO most of this is useless.  The actual intro to C++'
is useful and I learned some things from it.  It should have been longer
and more complete.  For example the discussion of multiple inheritance is
about 1.5 pages.  The discussion of segmentation of your project in the
first section is about 2 pages.  Which do you think is more important?

The third section has six chapters with code examples in each.  I would
say that these are informative.  There are some useful tips about using
TCL and using C++ in these chapters.  However, this book doesn't cover
some of the more advanced features of C++ like templates and friends (and
probably others that I've never heard of).

I suppose that my problem was that I wanted an in-depth book about C++
that emphasized the Mac, and such a book doesn't exist.

There are a couple of annoying things about the book.  All the TCL
documentation uses the terms 'instance variable' and 'method'.  The book
uses the terms 'member variable' and 'member function' and never mentions
that these are the same thing.  Also, the book uses an icon of a 5.25
floppy next to many of the source code examples.  I wonder if the
authors' 'Macs' use these :-/

Basically I don't think the book is worth US$40.  Also it's obsolete now
that SC++7 and TCL 2.0 are out.  Look for the sequel.

Brian Stern  }:-{)}
[e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Chris Gonna' Find Ray Charles Tate)
Date: Fri, 15 Apr 1994 14:29:11 GMT
Organization: DCRT, NIH, Bethesda, MD

In addition to learning C++, I'm going to assume you want to learn how
to program in an object-oriented manner.  This is not trivial; it
involves learning a new way of approaching programming, and of thinking
about things.

I recommend the book "Developing Object-Oriented Software on the
Macintosh," by Goldstein and Alger.  It's part of the Macintosh
Inside-Out series from Addison-Wesley, though I don't have its
ISBN number handy.  I *do* know that it's Addison-Wesley #57065,
list price $24.95.

It's an excellent discussion of the theoretical foundations of why
object-oriented software development is good, why it's hard to learn,
and what you can do about it.  The book also presents a (IMHO good)
methodology and notation for developing OO software.

- -------------------------------------------------------------
Christopher Tate             |  "So he dropped the heart -
MSD, Inc.                    |     the floor's clean."
[e-mail]    |                 - Sidney Harris

+++++++++++++++++++++++++++

>From John Brewer <[e-mail]>
Date: Sat, 16 Apr 1994 16:41:49 GMT
Organization: Wolfram Research, Inc.

In article <[e-mail]> Bob Jacobsen,
[e-mail] writes:
>What books do people recommend for C++ on the Mac?

I'd recommend some general C++ books to start out with.  Once you've
mastered the syntax and the key concepts of the language, then you can
branch out into platform-specific things like GUI frameworks.  Trying to
do everything at once will result in information overload.

If I were teaching a C++ class right now, I'd have the following books be
required reading:
Lippman, Stanley _The C++ Primer_ (If you don't know C) OR
Pohl, Ira(?) _C++ for C Programmers_ (If you do know C)
Budd, Timothy _An Introduction to Object Oriented Programming_

The following would be recommended supplemental reading:
Meyers, Scott _Effective C++_

You'll probably also want to pick up one or both of the following for
reference:
Stroustrup, Bjarne _The C++ Programming Language_
Ellis & Stroustrup _The Annotated C++ Reference Manual_

The reason I recommend either Lippman or Pohl is that, while Lippman is
probably the better book, it assumes you have no knowledge of C.  Since
Ihave over a decade of experience with C, I resent being told what a
"break" statement is again.  I also find that when I try to skip over
the stuff I already know, I invariably skip some new stuff by mistake.
Pohl assumes you know C, and therefore only covers the differences.  I
appreciate this approach.

Budd is a general book on object-oriented programming.  It deals with
primarily with general concepts, not syntax, and has examples in C++,
Objective C, Object Pascal, and Smalltalk.  It introduces the concepts
of classes and inheritance, as well as responsibility-driven design and
CRC cards.

Meyers is the best _second_ book on C++ that I know of.  It contains a
lot of general tips for writing better code.  The introduction alone
explained copy constructors better than some entire books.

I don't recommend Stroustrup as an introduction to C++, as it is way too
terse, but you really need it and/or the ARM as a language reference.

Good luck!

John Brewer
Wolfram Research, Inc.
(but speaking for myself)

+++++++++++++++++++++++++++

>From [e-mail] ( nick.c )
Date: 20 Apr 94 01:48:56 GMT
Organization: (none)

In Article <[e-mail]>, [e-mail] (Bob
Jacobsen) wrote:
>What books do people recommend for C++ on the Mac?
>
>Two suggestions have been:
>
>1) Learn C++ on the Macintosh, Dave Mark (1993).  Comes with Thin C++ and a
>cheap (how much?) upgrade offer.

   Dave's book is good (I have it), but is kind of a "vol 2" to his
    _Learn_C_on_the_Macintosh_, I think it would be hard to learn from
    unless you'd read "vol 1".  If you're already an ace at C - you'll
    probably get a lot out of it.

   I found an interesting book called _Symantec_C++_for_the_Macintosh:_
    the_Basics_, by John May and Judy Whittle.  It trys to explain
    C++ without refering to C, and is very specific to the Symantec
    environment.  Unlike the two books you mentioned, this one is
    stand alone (kind of impressive when you think of what it's trying
    cover).  It's not as detailed as having a seperate book on
    C, on your environment, and on C++ - but it's very convenient to
    have most of that info in one cover, and have it all with respect
    to Symantec's environment.

                                        -- nick



   _/   _/  _/  _/_/_/   _/   _/  Sea Shells to C shells,  Waikiki to
  _/_/ _/  _/  _/   _/  _/_/_/     the Internet, a wave, is a wave...
 _/ _/_/  _/  _/       _/ _/
_/   _/  _/   _/_/_/  _/   _/  CompSrv: 71232,766 I-Net: [e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (David J. Wang)
Date: Thu, 21 Apr 1994 00:24:07 GMT
Organization: Genome Database

nick.c ([e-mail]) wrote:
>In Article <[e-mail]>, [e-mail] (Bob
>Jacobsen) wrote:
>>What books do people recommend for C++ on the Mac?
>>
>>Two suggestions have been:
>>
>>1) Learn C++ on the Macintosh, Dave Mark (1993).  Comes with Thin C++ and a
>>cheap (how much?) upgrade offer.

>   Dave's book is good (I have it), but is kind of a "vol 2" to his
>    _Learn_C_on_the_Macintosh_, I think it would be hard to learn from
>    unless you'd read "vol 1".  If you're already an ace at C - you'll
>    probably get a lot out of it.

I have a different opinion about this -- I Learn C on the Macintosh --
and found it to be inadequate in dealing with both C as well as the
Macintosh.  There is a minimal amount of information dealing with the
macintosh (I now have Macintosh C Programming Vol. and wouldn't know
what to do without iit -- although I wish I didn't have to pay $30 for
the source on disk), and a barely adequate amount of info. dealing
with C. I looked through Learn C++... today, and it appeared to be the same
situation.

I hear from others around here that the Pohl book is very good
however, and I own C by Dissection (Pohl, Kelley).
--
*************************************************************************
David J. Wang                 #include <std_disclaimer>
[e-mail]                 [phone]
[e-mail]         Biology@The Johns Hopkins University
                     Baltimore, Maryland 21210
************************************************************************/

+++++++++++++++++++++++++++

>From [e-mail] (Bootstrap1)
Date: 23 Apr 1994 22:56:02 -0400
Organization: America Online, Inc. (1-800-827-6364)

In Article <[e-mail]>, [e-mail] (Bob
Jacobsen) wrote:
> What books do people recommend for C++ on the Mac?

I bought Stroustrup's The C++ Programming Language a few years ago and really
didn't care for it.  I've looked for a really good book on the subject ever
since and last year came across Bruce Eckel's C++ Inside & Out.  For me, it hit
the nail on the head; it was easy to read, gave good examples, and, best of
all, gave insight on the workings of the language behind the scenes, something
a lot of C++ books neglect.

---------------------------

>From [e-mail] (James D. Berry)
Subject: Native PPC Interrupt Control?
Date: Thu, 14 Apr 1994 14:57:47 -0700
Organization: Consultant

Is there interface level support for disabling interrupts on the PowerMac?
I know that application code runs at User Level, but haven't tried hitting
the EE bit in the MSR (which I would presume would cause an exception that
might or might not get properly emulated). Is this the only level of
support? Or is there some hook into the nanokernel to set the interrupt
level?

This is required to enforce mutual exclusion (since we don't yet have good
kernel level support--I want V1/NuKernel!) and I don't want to enter the
emulator just to modify the interrupt level.

--
James Berry
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Charlie Reiman)
Date: Fri, 15 Apr 1994 07:07:27 GMT
Organization: NETCOM On-line Communication Services (408 241-9760 guest)

[e-mail] (James D. Berry) writes:

>Is there interface level support for disabling interrupts on the PowerMac?
>I know that application code runs at User Level, but haven't tried hitting
>the EE bit in the MSR (which I would presume would cause an exception that
>might or might not get properly emulated). Is this the only level of
>support? Or is there some hook into the nanokernel to set the interrupt
>level?

>This is required to enforce mutual exclusion (since we don't yet have good
>kernel level support--I want V1/NuKernel!) and I don't want to enter the
>emulator just to modify the interrupt level.

I can't say for sure about disabling interrupts, but I have been
attacked by user mode limits on my PPC hacking. If all you need is
simple mutex stuff, get a 601 manual and look in the back for the code
examples covering mutuexes (mutexi? or is that a breakfast cereal...)
Or just look up information on load/store with reservation.
--
"You can't cancel the project! We already made the T-shirts!"
Charlie Reiman
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Anton Rang)
Date: 16 Apr 1994 00:02:23 GMT
Organization: Minnesota Angsters

In article <[e-mail]> [e-mail] (Charlie Reiman) writes:
>If all you need is simple mutex stuff, get a 601 manual and look in
>the back for the code examples covering mutuexes (mutexi? or is that
>a breakfast cereal...)  Or just look up information on load/store
>with reservation.

  That works great if you have two competing user-level threads.  If
you're trying to synchronize against interrupt-level routines (like an
I/O completion routine, driver, VBL task), you can't easily use a
mutex because there's no convenient way to ask the system to schedule
the running task for a later time.

  Of course, you can always implement your own process scheduler and
run everything through it (I did this once for a Nubus card driver
back when I was young and foolish).  But it's very difficult to make
sure that every case is properly handled, and it shouldn't be that
much work....
--
Anton Rang ([e-mail])

+++++++++++++++++++++++++++

>From [e-mail] (Anton Rang)
Date: 15 Apr 1994 00:23:58 GMT
Organization: Minnesota Angsters

In article <[e-mail]> [e-mail] (James D. Berry) writes:
>Is there interface level support for disabling interrupts on the PowerMac?

  There is absolutely no documented way to do this, and I'm very leery
of digging into the nanokernel to do it.  I've had several engineers
from Apple tell me that I shouldn't even think about it.  No word yet
on whether this will be added at some point, though I've heard that
the group working on porting the Appletalk protocol stack has
requested such a capability.

  I understand *why* they don't want people messing with interrupts
(especially with Geoport support and such), but at the same time, it's
a major bottleneck in the driver-level work I'm doing.

>This is required to enforce mutual exclusion (since we don't yet have good
>kernel level support--I want V1/NuKernel!) and I don't want to enter the
>emulator just to modify the interrupt level.

  And if you enter the emulator, it only modifies the emulator's
interrupt level.  You can still get low-level interrupts, though I
believe that currently all system-call-back interrupts (e.g. VBL
tasks, Time Manager, etc.) go through the emulator and thus obey the
restriction.

  I need mutual exclusion for a memory pool (darn Memory Manager won't
run at interrupt time :-), and an allocation/free pair which takes 4us
in PPC code takes nearly 100us if I switch into and out of emulation
for it.  Really sucks.

 Anyone from Apple listening to our pleas?  (Anyone with the $$$ to be
an Apple Partner who might have clout enough to let us call the
nanokernel for this until NuKernel is out?)
--
Anton Rang ([e-mail])
>From Eric Anderson <[e-mail]>
Subject: Native PPC Interrupt Control?
Date: Tue, 19 Apr 1994 03:06:46 GMT
Organization: Apple Computer

Re: Native PPC Interrupt Control?


Yes, folks here at Apple are listening to your pleas. In fact, if you
look at the native Thread Manager, you will note the lack of preemptive
threads - this is because the native interrupt runtime model is not
exported outside the kernel. Yes, we need to wait for the new kernel
before we get such native niceties as native interrupt handling (in some
form(s)) to provide better I/O and tasking services both inside Apple and
from our developer community.

Eric Anderson
Mac OS
Apple Computer, Inc.

+++++++++++++++++++++++++++

>From [e-mail] (Benjamin Herrenschmidt)
Date: Tue, 19 Apr 94 23:01:05 +0100
Organization: (none)

>
>In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Anton Rang) writes:
>
>In article <[e-mail]> [e-mail] (James D. Berry) writes:
>>Is there interface level support for disabling interrupts on the PowerMac?
>
>  There is absolutely no documented way to do this, and I'm very leery
>of digging into the nanokernel to do it.  I've had several engineers
>from Apple tell me that I shouldn't even think about it.  No word yet
>on whether this will be added at some point, though I've heard that
>the group working on porting the Appletalk protocol stack has
>requested such a capability.
>
>  I understand *why* they don't want people messing with interrupts
>(especially with Geoport support and such), but at the same time, it's
>a major bottleneck in the driver-level work I'm doing.
>
>>This is required to enforce mutual exclusion (since we don't yet have good
>>kernel level support--I want V1/NuKernel!) and I don't want to enter the
>>emulator just to modify the interrupt level.
>
>  And if you enter the emulator, it only modifies the emulator's
>interrupt level.  You can still get low-level interrupts, though I
>believe that currently all system-call-back interrupts (e.g. VBL
>tasks, Time Manager, etc.) go through the emulator and thus obey the
>restriction.
>
>  I need mutual exclusion for a memory pool (darn Memory Manager won't
>run at interrupt time :-), and an allocation/free pair which takes 4us
>in PPC code takes nearly 100us if I switch into and out of emulation
>for it.  Really sucks.
>
> Anyone from Apple listening to our pleas?  (Anyone with the $$$ to be
>an Apple Partner who might have clout enough to let us call the
>nanokernel for this until NuKernel is out?)
>--
>Anton Rang ([e-mail])

I completely agree with you ! as a Nubus card driver designer and
a low level developper (i work on drivers, interrupts, network software
etc...), a way to mask interrupts is VERY important. It is the only
way to do some tasks at interrupt level. Another VERY important thing
is to be able to do atomic read-test-modify like the TAS instruction
of the 68K to do semaphores. They are REQUIRED to work with "resources"
shared between several processors. (main processor and a DSP for example).

It would be a VERY BAD thing from apple to remove the ability of having
uninterruptible pieces of code and atomic semaphores.

I hope Apple will soon release a technote with everything we MUST
know about these. (remeber that not all macintoshes support the TAS
instruction which is really a pain when you have to build an interface
between the mac and another processor, on a PDS card for example).

Hey, Apple ! do you listen to us ? will you do it ?

BenH.


+++++++++++++++++++++++++++

>From [e-mail] (MRustad)
Date: 23 Apr 1994 01:05:05 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]>, [e-mail] (Benjamin
Herrenschmidt) writes:

>I hope Apple will soon release a technote with everything we MUST
>know about these. (remeber that not all macintoshes support the TAS
>instruction which is really a pain when you have to build an interface
>between the mac and another processor, on a PDS card for example).

Ben,

TAS is not all that important. I did the multiprocessor interlocking for A/ROSE
and could not use TAS at all anywhere (even for single processor
locks) due to nasty bus error conditions that could arise with the 68000
coprocessors. In previous positions I worked on CDC Cybers that had a bunch of
processors in the box and nothing remotely like a TAS. There are lots of neat
tricks that really work better than TAS anyway.

Of course, you can continue to use the emulator, which does TAS for you, if it
is that important to you (but my stuff will run faster than yours!).

-Mark Rustad, [e-mail]

---------------------------

>From [e-mail] (Michael A. Walker)
Subject: SetDialogDefaultItem in a modal dialog
Date: Wed, 20 Apr 1994 09:15:01 -0500
Organization: New York University

Hi. Please forgive this question if it's a FAQ.  I'm trying to use
SetDialogDefaultItem for a modal dialog and I'm having some
problems (well, one problem--it's not working ;-).  Within my
routine that displays the dialog, I call SetDialogDefaultItem
as I'm suppose to do.  The problem comes in when I call
ModalDialog using my own dialog filter which is used to control
a read-only scrolling text region.  Somehow, the call to
SetDialogDefaultItem is reversed or ignored since I added the
dialog filter.  Here is a snippet of the code:

void ShowAbout(void)
{
    DialogPtr        dialog;
    Boolean        dialogDone = false;
    short        itemHit, itemType;

/* deleted stuff */

    dialog = GetNewDialog(kAboutResID, nil, kMoveToFront);

    SetDialogDefaultItem(dialog, ok);
    SetDialogTracksCursor(dialog, true);

/* deleted stuff */

    ShowWindow(dialog);
    SetPort(dialog);

    GetDItem(dialog, ok, &itemType, &okItemHandle, &itemRect);

    /* you guessed it, more deleted stuff */

    while (! dialogDone) {
        ModalDialog(AboutDlgFilter, &itemHit);
        switch (itemHit) {
            case ok:
                dialogDone = true;
                break;
        }
    }

    DisposDialog(dialog);
}

Is there something else I have to do?

Thanks in advance.

--
Michael A. Walker
New York University
[e-mail]
==============================================------------------------8-;
main() {int x,y,k;char *b=" .:,;!/>)|&IH%*#@";double
cr,ci,zr,zi,temp,cx,cy;
for(y=30;puts(""),cy=y*0.1-1.5,y-->=0;){for(x=0;cx=x*0.04-2,zr=0,zi=0,x++<75;)
{for(cr=cx,ci=cy,k=0;temp=zr*zr-zi*zi+cr,zi=2*zr*zi+ci,zr=temp,k<112;k++)
if(zr*zr+zi*zi>10)break;printf("%c",b[k%16]);}}}      /*  try this on for
size!!  */

+++++++++++++++++++++++++++

>From [e-mail] (Kevin R. Boyce)
Date: Wed, 20 Apr 1994 12:46:05 -0400
Organization: NASA/GSFC

In article <[e-mail]>,
[e-mail] (Michael A. Walker) wrote:

> Hi. Please forgive this question if it's a FAQ.  I'm trying to use
> SetDialogDefaultItem for a modal dialog and I'm having some
> problems (well, one problem--it's not working ;-).  Within my
> routine that displays the dialog, I call SetDialogDefaultItem
> as I'm suppose to do.  The problem comes in when I call
> ModalDialog using my own dialog filter which is used to control
> a read-only scrolling text region.  Somehow, the call to
> SetDialogDefaultItem is reversed or ignored since I added the
> dialog filter.

You didn't include your dialog filter, but I bet it doesn't call the
standard filter proc.  Here's one that doesn't handle any dialog events,
but correctly passes update events on to other windows (this is taken
almost verbatim from the "Pending Update Perils" technote):

pascal Boolean BasicDlogFilter( DialogPtr currentDialog,
 EventRecord *theEventIn, short *theDialogItem)
{
    OSErr                myErr;
    ModalFilterProcPtr    standardProc;
    Boolean                returnVal = false;
    WindowPtr            temp;

    if( (theEventIn->what == updateEvt) &&
     (theEventIn->message != (long)currentDialog) )
    {
        returnVal = DoUpdate(theEventIn);    /* go to my update routine */
    }
    else
    {
        GetPort(&temp);
        SetPort(currentDialog);
        myErr = GetStdFilterProc((ProcPtr)&standardProc);
        if(!myErr)
            returnVal = standardProc( currentDialog, theEventIn, theDialogItem );
        SetPort(temp);
    }
    return(returnVal);
}

(Apologies if the formatting is screwed up.  Boy I wish NewsWatcher handled
tabs correctly.  Time to take another look at the source...)


--
Kevin      [e-mail]
You can blow out a candle, but you can't blow out a fire.
Once the flame begin to catch, the wind will blow it higher.
           --Peter Gabriel, 1980  (_Biko_)

+++++++++++++++++++++++++++

>From Stephan Bublava <[e-mail]>
Date: 21 Apr 1994 06:08:54 GMT
Organization: Vienna University of Technology

In article <[e-mail]> Michael A.
Walker, [e-mail] writes:

>Hi. Please forgive this question if it's a FAQ.  I'm trying to use
>SetDialogDefaultItem for a modal dialog and I'm having some
>problems (well, one problem--it's not working ;-).

>[snip]

>Somehow, the call to SetDialogDefaultItem is reversed or ignored
>since I added the dialog filter.

You must call the default filter from your modal dialog filter.
How to to this is described in the TechNote that describes the
new Dialog Manager routines.

Stephan

--
Stephan Bublava
[e-mail]

---------------------------

>From [e-mail] (Christopher R. Bailey)
Subject: Symantec has an FTP site!
Date: 22 Apr 1994 15:34:28 GMT
Organization: DejaView Software, Inc.

Maybe most of you already know this, but I didn't and I've never seen anything
about it.  I was sick of waiting for the CPlusLib update from Symantec for
7.0.  So I called them, and the guy told me to ftp to their site:

    devtools.symantec.com

Sure enough it was there, along with all the other updates.  Now, why couldn't
Symantec post on here telling us about that?  I realize they may not want
their ftp machine getting loaded up, but if they don't, then they should have
posted it to Sumex (as if we can get in there).  I wasted a phone call, as
well as I've probably now started that totally lame limited 90 days of support
crap that they've started.  What a joke!  (Hmm, it seems Symantec bashing is
now a required part of every post on these groups :)

--
________________________________________________________
  Christopher Bailey        Work: [e-mail]
  Software Engineer         Home: [e-mail]
  DejaView Software Inc.    http://bigmac.gmg.com/

---------------------------

>From Ben J Fry <[e-mail]>
Subject: pascal and c libraries
Date: Tue, 19 Apr 1994 21:31:59 -0400
Organization: Freshman, Design, Carnegie Mellon, Pittsburgh, PA

is there any way to write a function in think pascal and have it
available for use in a think c project? how would this be done, and how
would you do the opposite, compiling something in c and calling it from
pascal?

thanks in advance...

ben
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Ingemar Ragnemalm)
Date: 22 Apr 1994 09:24:52 GMT
Organization: (none)

Ben J Fry <[e-mail]> writes:

>is there any way to write a function in think pascal and have it
>available for use in a think c project? how would this be done, and how
>would you do the opposite, compiling something in c and calling it from
>pascal?

Both are quite possible. I've even had projects where I write a lib mostly
in Pascal, but calling a C-lib (for the inline assembler). Then I make a
library of it, so my C-using friend can use it. That means that the code
has three layers, C-Pascal-C!

Using C from Pascal is simple. The C functions must be declared "Pascal".
You build a library and write an interface file.

Using Pascal from C takes a bit more, mostly due to limitations in the
Think compilers, and very poor documentation. (May I say "bugs"?)

You build a library from the Pascal code and convert it with oConv.

BUT something is wrong with how either Think Pascal sets the function names
or how oConv converts them, so capitalization might get wrong. You can fix
that by checking the ".v" box, edit the .v file to he correct capitalization
in the cases where you get problems, and then oConv again, still with ".v"
checked.

BUT your Pascal library might rely on some of Think Pascal's built-in
functions, usually LMUL and LDIV. The fix I've been recommended, and that
I am using, is to include uRuntime.lib in the Pascal library. This works
just great with Think C 5. (Note that Symantec's support people seem to
know nothing about how to do this.)

BUT Think C version 6 has a bug in its linker! If you include uRuntime.lib,
you get a link error telling you that a function isn't defined - a function
that is in the ROM's since 1984! (MaxApplZone if I remember right.) This can
be fixed by opening the library and remove a segemnt that is named %_TOOLBOX
(or something like that).

BUT that is only possible using Think C 5! If you don't have Think C 5,
you'll have to ask someone who has it to do it. I guess we could convert
uRuntime.lib to a C library and remove it, and post...

BUT is that legal, or is it breaking some copyright that Symantec has?

If you have Think C 5, it isn't a big problem.

The whole problems should be simpler with CodeWarrior. Can anyone confirm
that?



--
- -
Ingemar Ragnemalm, PhD
Image processing, Mac shareware games
E-mail address: [e-mail] or [e-mail]

---------------------------

End of C.S.M.P. Digest
**********************